Skip to content

Conversation

@rouault
Copy link
Member

@rouault rouault commented Oct 14, 2025

... following directions of a discussion happening at the Zarr Developer Summit 2025.

It transposes https://github.com/EOPF-Explorer/data-model/tree/main/attributes/geo/proj to that attribute framework.

Example:

{
  "attributes":{
    "zarr_conventions_version": "0.1.0",
    "zarr_conventions":
    {
        "f17cb550-5864-4468-aeb7-f3180cfb622f": {
            "version": "0.1",
            "name": "geo/proj",
            "description": "",
            "schema": "http://example.com/geo.proj.schema.json",
            "configuration": {
                "code": "EPSG:26711",
                "spatial_dimensions": ["Y", "X"],
                "transform": [60, 0, 440720, 0, 60, 3750120]
            }
        }
    }
  }
}

…ute conventions... [ci skip]

... following directions of a discussion happening at the Zarr Developer Summit 2025.

It transposes https://github.com/EOPF-Explorer/data-model/tree/main/attributes/geo/proj to
that attribute framework.
}
}
}
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be at the group level?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from https://github.com/EOPF-Explorer/data-model/tree/main/attributes/geo/proj#description

Recommended usage: Store the CRS-encoding JSON object defined in this specification under the proj key in the attributes of a group that contains arrays to declare CRS metadata for those arrays. This supports the common geospatial practice of storing multiple arrays with the same coordinates in a single group. Array-level definitions are supported for override cases but are less common.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This supports the common geospatial practice of storing multiple arrays with the same coordinates in a single group

That's something we need to discuss. My initial feeling is that I'm no a huge fan of having stuff defined only at an upper level when potentially users can point GDAL to open a inner group directly or an array. So that means either such use case will be invalid, or GDAL would need to walk up the hieararchy (but where to stop?) which involves extra I/O

@github-actions
Copy link

The GDAL project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 28 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

  • that all unit tests are passing

  • that all comments by reviewers have been addressed

  • that there is enough information for reviewers, in particular link
    to any issues which this pull request fixes

  • that you have written unit tests where possible
    In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
    If there is no further activity on this pull request, it will be closed in 2 weeks.

@github-actions github-actions bot added the stale label Nov 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants